With the proliferation of the Internet and applications utilizing Internet or other networking systems, increasingly, data has been accessed from servers using diverse platforms in varied locations and circumstances. Currently, a variety of Internet clients are available for accessing Internet information, including embedded devices (e.g., browsers in household appliances), palm size personal computers, palm size organizers, desktop personal computers, lap top computers, cellular telephones and other platforms that are being developed presently. The diversity of platforms available for accessing Internet content is expected to expand, particularly as wireless data networks become increasingly available to users.
Each of the variety of clients currently available has unique memory performance and functionality constraints. The unique physical characteristics of each client, or the desired functional use of the client, implies that each client will have different processing code and different input/output functionalities available to it.
This diversity of platforms raises a number of difficulties. First, most Internet content, and content on other networks such as corporate intranets, has been developed to facilitate communication with a single type of client, namely, a desktop or notebook computer having a standard size display screen, a full alpha/numeric keyboard, and frequently also a pointing device. Content developed for this client platform is not well suited for use in and viewing on other dramatically different platforms, such as embedded devices, palm size personal computers, organizers and cellular telephones. To date, the content that is easily available through such non-standard platforms has been limited to that made available in conjunction with the manufacturer of the client hardware.
Second, diverse platforms require different software capabilities to handle content delivered over a network; these capabilities are difficult to predict in advance or to install in advance of their desired use. Although it has been known to install functions for Internet content on an as needed basis, the methodologies that have been developed are not particularly suitable for diverse clients with varied and potentially highly limited capabilities and resources.
For example, Microsoft Internet Explorer includes an install on demand feature in which Internet Explorer will recognize when given functionality is needed to properly present web page content, and in this condition will prompt the user to download and install the needed functionality. The difficulty with this approach is that the installed functionality is permanently installed at the client computer, and thus may consume precious resources, particularly where the client has limited resources such as is the case in palmtop or cellular telephone clients.
A second example, the Java Virtual Machine functionality has been promulgated by Sun Microsystems as an open source programming language for use with web-based content. In a Java-enabled website, Java Virtual Machine (VM) code for a page is downloaded and initiated as part of viewing the page. The Java Virtual Machine code is retained in memory and executed, so long as the page is viewed by the user. When the user departs the page the Java Virtual Machine code is discarded. A difficulty with the Java methodology is that the Java Virtual Machine code for a given web page is identical for all clients visiting the page, and thus is not adaptable for clients with radically different functionalities and capabilities. Furthermore, the Java Virtual Machine code for a web page is downloaded in full upon accessing the page, potentially requiring resources in excess of those available in a client with limited computing or storage capabilities. Finally, because Java Virtual Machine code is discarded upon exiting the page associated with the code, the user upon returning to that page must reinitialize his or her browsing state, such as information retrieved or data entered, because that state information is not retained when the Java Virtual Machine code is discarded.
A third difficulty arising from the use of diverse clients with potentially widely varying capabilities, arises when attempting to retain information on the state of interaction of the client with the server. Web browsers such a Microsoft Internet Explorer have incorporated a functionality known as “cookies”. In this methodology, a server may store a small file known as a “cookie”, on a client computer, that contains some status information. “Cookie” files are stored and retrieved by the server, under supervision of the client's browser software. In some cases, cookies may be used to restore the state of a user upon return to a web page. However, cookies may consume an inordinate amount of a client's storage resources. Furthermore, due to security concerns, many users dislike the “cookie” approach of storing information on a client's computer system. For either or both reasons, many users prevent storage of cookies on their client systems.
A further, related, difficulty arises in a server attempting to provide services to a wide variety of clients. Specifically, in a typical server, all data and executable code needed to provide services to clients that may connect to the server, are loaded in the server at all times. This approach, while insuring that all possible services are always available from a server, can consume substantial resources of a server. This is particularly true where multiple different styles of clients and/or multiple different services may be utilized from the server. As unique executable code or data is developed for different unique clients, the duplication and proliferation of different server functions will be exacerbated.
The UNIX daemon known as INETD, attempts to resolve this problem by defining a static list of services that may be provided by a server. This list is used to load needed services when those services are demanded by the server. Unfortunately, the UNIX INETD daemon suffers from the limitation that the services provided by the server must be predefined and be in a static listing, limiting the adaptability of the server to changing conditions.
It can thus be seen that the state of the art has substantial limitations in managing, on both the client and server, the emerging environment characterized by diverse clients connecting to server for providing services over a network.
In the preceding discussion, and in the follow explanation, of the invention, the word “service” will be used to refer to executable code or an executable process, or data utilized in such a process, or both, in any combination, that provides an information handling function. Furthermore, a “service” will be understood to comprise client and server components, which interact to provide an information handling function, each component of which may include executable code, data, or both, in any combination. The client and server portions of the service interact and interoperate to provide the desired overall information handling functionality of the service.